home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 597 < prev    next >
Internet Message Format  |  1994-08-27  |  2KB
  1. Date: Sat, 18 Jun 1994 09:06:06 -0400 (EDT)
  2. From: Rick Flashman <rflashma@mhc.mtholyoke.edu>
  3. Subject: Comments
  4. To: Atari GEM Mailing List <gem-list@world.std.com>
  5. Message-Id: <Pine.3.89.9406180850.B9341-0100000@mhc.mtholyoke.edu>
  6. Mime-Version: 1.0
  7. Precedence: bulk
  8.  
  9. I must say that I am a little confused. I was asked to join this 
  10. "gem-list" to assist in developing a new standard of keyboard equivalets. 
  11. Mostly because we develop some of the three best selling programs in the 
  12. North American market (NeoDesk, Geneva, and STalker).  Therefore we have 
  13. a substancial influence over the more popular keyboard equivalents here.
  14.  
  15. This is especially true in the case of Geneva. After all, who cares if an 
  16. old program doesn't support the "control-U" for closing a window, as long 
  17. as your operating system does (same result).
  18.  
  19. However, it seems that we are here too late.  The standard is already 
  20. decided on, and not subject to much discussion. I don't know who the 
  21. senior committee was that decided on it, but we are not too comfortable 
  22. not having been invited to be part of it.
  23.  
  24. All these "Control" keyboard equivalents are great, but I'm not sure how
  25. we are supposed to implement them in programs like STalker or STeno (one
  26. is a terminal that needs the control keys for communications, the other is
  27. a text editor that supports entering control keys). 
  28.  
  29. If we had been here earlier (before the standard was decided on) we would
  30. have argued for ALT-everything. It is not used by many programs (so
  31. everyone is in the same boat and has to change), and leaves the entire 
  32. CONTROL set open for programs to use for "custom" commands.
  33.  
  34. So, I guess that the next step for us is just to wait for the key file 
  35. format to come out (from wherever it is that it is coming out). Then we 
  36. will take a look at it and decide if we should support it in our next 
  37. revisions (depending on how the rest of the market accepts it).
  38.  
  39. Rick Flashman,
  40. Gribnif Software
  41.